Next | Prev | Up | Top | Contents | Index

CHALLENGE/Onyx Family Support

The CHALLENGE/Onyx family architecture has added new features and restrictions on the drivers, configuration, and other tools that could not be dealt with by the existing software framework. Supporting these systems with the common source used for all Silicon Graphics products necessitated changes in the way kernels are configured and support in for the new hardware features.

Some of the CHALLENGE series architecture differences include:

These differences cause the following software changes:

  1. The need for a general mechanism for probing for devices on multiple and different types of buses caused changes to the VECTOR line to specify which type of bus, which bus of that type, which address space on that particular bus, which address on that bus, and so on. Since there are no automatic K2 addresses, the addresses are abstracted and more meaningful than they were in the past. Different buses require different types of information, as well. VME has interrupts specifying both a vector and IPL, whereas EISA does not. So, a bus-specific portion was added to the edt structure. This caused the need for new VECTOR line probing specifications, as well.

  2. Since there are no known K2 addresses that correspond to VME-bus locations, user-level VME drivers can no longer be performed through /dev/mmem, but instead, they now have their own /dev/vme device interface. This also affects kernel drivers. Kernel drivers must map in the address space of their controllers before they can access them. This is done with special pio_mapping routines, similar to existing DMA mapping routines. This is further complicated by the fact that, for VME A32 space, pio_mapping registers are a limited resource. Only 13*8 MB can be mapped into the kernel at any one time; so 12 of these registers can be locked down and the thirteenth used as a floater to be shared by whoever needs it, from drivers to lboot.

    Note: A32 pio_mappings start and end on 8 MB boundaries. The address you map plus the length of the mapping must not cross an 8 MB boundary.

  3. Since VME-bus controllers cannot access physical memory directly, you can no longer pass the controller a K0 address and expect it to work. EVERYTHING has to be DMA mapped. For example, in the past, IOPB addresses were normally converted to K0 addresses and passed to the controller. Now the IOPBs must be DMA mapped.

  4. Some new functionality has been added to the VME driver interface. Since most VME boards can have their IRQ vector and ipl programmed through software, it is now possible to allocate VME vectors dynamically, so they need not be specified on the VECTOR line. This frees you from worrying about finding one that is not already in use. Simply call vme_ivec_alloc() to allocate a free vector, then call vme_ivec_set() to register your interrupt routine.

  5. The driver interface now uses the SVR4 MP DDI/DKI interface except for the Silicon Graphics-specific routines, such as pio_map() and dma_map(). For example, entry points such as open, close, read, and write all have slightly different arguments and, in some cases, different procedure types, in 5.x than they had in earlier versions.

  6. The DDI/DKI drvrflags variable, not the flag in the master.d file, is used for the driver to indicate that it is MP-safe.

Next | Prev | Up | Top | Contents | Index